Hi, is there a chance to have this PR merged?

I'm not opposed to the feature generally. But I don't think this approach is the right solution because it won't work for other nested data. I also think that generally most Meteor devs don't use ObjectIDs so it'd be nice to find a way to support the feature without incurring a performance penalty, ideally also without needing to configuring anything.

Thanks for your reply. You're right it based of my usecase (referencing others documents from other collections ar top level).
For zero confugiration, an config parameter (false be default) could b added to enable or not this feature. So most of people will have nothing to set up.
For nested data, it must be recursive but we could limit the depth with a config parameter.

Hmm, I don't love the idea of adding multiple configs for this.

One idea would be to apply it if the collection is known to have idGeneration: MONGO and not limit the depth.

Maybe there is an even simpler solution. I haven't looked at how previous indexeddb solutions dealt with it. Let me know if you come up with a simpler solution.

I did a few tests. It seems that using EJSON.toJSONValue and EJSON.fromJSONValue preserves the ObjectId type and could be more generic.

One idea would be to apply it if the collection is known to have idGeneration: MONGO and not limit the depth.

I think it will not work as you can have collection withoutidGeneration: MONGO which will contain documents with ObjectID field.
EJSON.toJSONValue and EJSON.fromJSONValue work pretty well. The issue I have is with the index creation.

I did not test with the jam:archive package. Just want to know if you're OK with the modification.